IRIX Base Documentation 2002 November

home *** CD-ROM | disk | FTP | other *** search

/ IRIX Base Documentation 2002 November / SGI IRIX Base Documentation 2002 November.iso / usr / share / catman / p_man / cat5 / ipa.z / ipa

Wrap

Text File | 2002-10-03 | 37.5 KB | 692 lines

IPA(5) Last changed: 4-9-99 NNAAMMEE IIPPAA - Inter-Procedural Analysis IIMMPPLLEEMMEENNTTAATTIIOONN IRIX systems DDEESSCCRRIIPPTTIIOONN This man page describes Inter-Procedural Analysis (IPA) in the MIPSpro compilers and how to use it most efficiently. IIPPAA OOvveerrvviieeww Most compiler optimizations work within a single procedure (for example, function or subroutine) at a time. This helps keep the problems manageable, and is a key aspect of supporting separate compilation, because it allows the compiler to restrict attention to the current source file. This intra-procedural focus also presents serious restrictions. By avoiding dependence on information from other procedures, an optimizer is forced to make worst-case assumptions about the possible effects of those procedures. For instance, at boundary points including all procedure calls, the compiler must typically save (and/or restore) the state of all variables to or from memory. By contrast, IPA algorithms analyze more than a single procedure (preferably the entire program) at once. The optimizations performed by the MIPSpro compilers' IPA utility include: * _I_n_l_i_n_i_n_g: Calls to a procedure are replaced by a suitably modified copy of the called procedure's body inline, even if the callee is in a different source file. * _C_o_m_m_o_n _b_l_o_c_k _a_r_r_a_y _p_a_d_d_i_n_g: Global arrays in Fortran may be padded (that is, their size increased in order to reduce cache conflicts). * _C_o_n_s_t_a_n_t _p_r_o_p_a_g_a_t_i_o_n: Formal parameters which always have a particular constant value can be replaced by the constant, allowing additional optimization. Global variables which are initialized to constant values and never modified can be replaced by the constant. * _D_e_a_d _f_u_n_c_t_i_o_n _e_l_i_m_i_n_a_t_i_o_n: Functions which are never called can be removed from the program image, improving memory utilization. * _D_e_a_d _v_a_r_i_a_b_l_e _e_l_i_m_i_n_a_t_i_o_n: Variables which are never actually used can be eliminated, along with any code that initializes them. * _G_l_o_b_a_l _n_a_m_e _o_p_t_i_m_i_z_a_t_i_o_n_s: Global names in shared code must normally be referenced via addresses in a global table, in case they are defined or preempted by another dynamic shared object (DSO). If the compiler knows it is compiling a main program and that the name is defined in another of the source files comprising the main program, an absolute reference can be substituted, eliminating a memory reference. For example, the following code can be used to to load XX: lw $4,%got_disp(X),$gp ld $5,0,$4 It could be changed to the following: lui $4,%hi(X) ld $5,%lo(X),$4 Similarly, IPA can optimize the data items that can be referenced by simple offsets from the GP register instead of depending on the user to provide an ideal value of the --GG option (see cccc(1) or ff7777(1)). IIPPAA aanndd CCoommppiillaattiioonn Because IPA must usually process code from multiple source files to be effective, it has significant effects on compilation. These can be classified as affecting either the program build process itself, or the attributes of the resulting program. TThhee BBuuiilldd PPrroocceessss The standard Unix C or Fortran compilation model involves two steps. First, each source file comprising a program is compiled independently of the others, producing a relocatable _o_b_j_e_c_t file with the ..oo extension. Then, the resulting object files are linked, along with any standard libraries, by lldd(1). IPA works by postponing much of the compilation process until the link step, when all of the program components can be analyzed together. Specifically, the following occurs: * The _c_o_m_p_i_l_e _s_t_e_p does initial processing of the source file, placing an intermediate representation of the procedures it contains into the output ..oo file instead of normal relocatable code. Such object files are called _W_H_I_R_L _o_b_j_e_c_t_s to distinguish them from normal relocatable object files. This choice is invoked by the --IIPPAA:: option. This processing is really two phases: the normal language processing, plus an IPA summary phase which collects local information to be used by IPA later. Because most optimization and code generation options are transmitted via the IPA summary phase, they must be present on the command line for the compile step. * The _l_i_n_k _s_t_e_p, although it is still invoked by a single lldd(1) command, becomes several steps. First, the linker invokes IPA, which analyzes and transforms all of the input WHIRL objects together, writing modified versions of the objects. Then it invokes the compiler on each of the modified objects, producing a normal relocatable object. Finally, it invokes the linker again for a normal linkage step, producing an executable program or DSO. The temporary files created during this expanded link step are all created in a temporary subdirectory of the output program's directory, unless the environment variable TTMMPPDDIIRR is specified, in which case the temporary subdirectory is created under $$TTMMPPDDIIRR; like other temporary files produced by the compilation process, they are normally removed on completion (unless the --kkeeeepp option is specified with the compiler command). IPA increases program build time in two ways. First, although the IPA step may not be very expensive itself, it usually increases the size of the code by inlining, and therefore expands the time required by the rest of the compiler. More importantly, because IPA analysis can propagate information from one module into optimization decisions in arbitrary other modules, even minor changes to a single component module cause most of the program compilation to be redone. As a result, IPA is best suited for use on programs with a stable source base. Because full IPA is not always suitable, the MIPSpro compilers also support inlining without IPA in cases where both the call and the called subprogram are in the same file. This feature, called the _s_t_a_n_d_a_l_o_n_e _i_n_l_i_n_e_r, is invoked by default when inlining is specified in C++, or may be explicitly invoked using the --IINNLLIINNEE options (described following). PPrrooggrraamm AAttttrriibbuutteess Like most optimization performed by the compiler, IPA should not change the program's behavior. Nevertheless, it can affect the resulting program in subtle ways. The most important effects involve external symbols and DSOs. Unlike other IPA implementations, the MIPSpro compiler does not require that all of the components of a program be subjected to IPA analysis. The lldd(1) command which invokes IPA may include object files (..oo) and archives (..aa) which have been compiled normally without IPA analysis, as well as referencing DSOs which, however they were compiled, cannot contribute detailed information because the DSO may be replaced with a different implementation after the program is built. To analyze the program's use (and non-use) of variables, IPA must determine what those unanalyzed objects might reference. It does so by examining their external symbol references. If an external symbol is never referenced by one of the unanalyzed objects, and its address is never taken in the code being analyzed, IPA can assume that the only possible way for the unanalyzed code to access the named object is if it passed as a parameter to an unanalyzed subprogram. Otherwise, it must make worst-case assumptions. This approach is safe for normal relocatable objects and archives, because they cannot be changed without rebuilding (and reanalyzing) the program. For DSOs, however, there is a danger that a modified version will make additional references. To prevent this from causing changed program behavior, IPA changes all of the external symbols which it assumes to be unreferenced to HHIIDDDDEENN or IINNTTEERRAALL export class, which prevents them from being referenced inadvertently by a future version of the DSO. The DSO case is safe as well. The DSO treatment does have an important side effect, though. All referenced DSOs should be referenced on the lldd(1) command line. Otherwise, their external references will not be seen by IPA, and the symbols they require may not be visible at runtime, causing failure. If you cannot give references to all DSOs used (for example because you will be accessing them with ddllooppeenn(3) and don't want them automatically loaded with your program), then you must provide an explicit exported symbol list with the --eexxppoorrtteedd__ssyymmbbooll or lldd(1) options. See ddssoo(5) for more information. Because IPA combines code from multiple source files, it is recommended that the same compilation options be used for every source file that is compiled with IPA analysis. If it is important for a single file to be given unusual compilation options that would be inappropriate for the rest of the program (such as rounding mode control), it is recommended that that file be compiled without IPA analysis. IIPPAA OOppttiioonnss IPA is controlled from the command line with two option groups. --IINNLLIINNEE:: controls inlining by the standalone inliner. It should be used on your compile command line. --IIPPAA:: controls general IPA choices. If you use separate compile and link steps (i.e. using --cc when you compile and then linking the ..oo files produced with a separate cccc, ff7777, or lldd command), then you need to use --IIPPAA for the compile step, with or without individual options described below, and also for the link step with any of the following options desired. The command line format used for group options is -_g_r_o_u_p_n_a_m_e::_o_p_t_i_o_n[[==_v_a_l_u_e]][[::_o_p_t_i_o_n_2[[==_v_a_l_u_e_2]]]]...... The _g_r_o_u_p_n_a_m_e (IIPPAA or IINNLLIINNEE) is followed by a colon-separated list of options, each of which is an option name possibly followed by an equal sign and a value. The option names may generally be abbreviated by truncating them to a unique prefix (which may change when new options are added to the group). Some _o_p_t_i_o_ns are specified with a setting that will enable or disable the feature. To enable a feature, specify the option alone or with ==11, ==OONN, or ==TTRRUUEE; to disable the feature, specify the option with ==00, ==OOFFFF, or ==FFAALLSSEE. This man page only shows the OONN or OOFFFF settings, but the other settings are equally valid. IINNLLIINNEE OOppttiioonnss The IINNLLIINNEE option calls the standalone inliner option group, which controls the application of subroutine inlining done by the standalone inliner, or by the main inliner if --IIPPAA options are enabled. Normally, the calls to be replaced by an inlined copy of the called subprogram are chosen by heuristics internal to the inliner. Most of the options in this group provide control over those choices. The individual controls in this group are: ==((_s_e_t_t_i_n_g)) Enables or disables stand-alone inlining processing. _s_e_t_t_i_n_g can be either OONN or OOFFFF. This is ignored with a warning for compiles which invoke main IPA processing. When both are used in the command line (for a compile which will not invoke main IPA processing), ==OOFFFF is processed and ==OONN is overridden with a warning. If used within a specfile read by the stand-alone inliner, ==OOFFFF skips inline processing within the stand-alone inliner and ==OONN is ignored with a warning. aallll Changes the default inlining heuristic to attempt to inline all routines which are not excluded by a nneevveerr option or a pragma suppressing inlining, either for the routine or for a specific callsite. This option conflicts with nnoonnee; aallll takes precedence if both are specified. This option may cause performance problems because the size of the procedures may be very large after inlining. If this option must be used, then increase the OOlliimmiitt by using the --OOPPTT::OOlliimmiitt==_n option to enable procedures to be optimized. See the oopptt(5) man page for details. This may affect compilation speed. aallllooccaa[[==_s_e_t_t_i_n_g]] Enables save/restore of stack when inlining calls with aallllooccaa. _s_e_t_t_i_n_g can be either OONN or OOFFFF. If the callee has an alloca, then inlining it would normally remove the function boundary at which the dynamic space would have been released. This option saves and restores the stack pointer before and after the inlined code. Having the option OONN is essential for correctness (for example, in code where the callee is inside a loop). The default is OONN. ddffee[[==_s_e_t_t_i_n_g]] Performs dead function elimination in the standalone inliner. _s_e_t_t_i_n_g can be either OONN or OOFFFF. This option removes any functions that are inlined everywhere they are called and are not visible outside the current module. C/C++: the default is TTRRUUEE when not compiled with --gg, FFAALLSSEE otherwise. ffiillee==_f_i_l_e_n_a_m_e Provides cross-file inlining from within the stand-alone inliner. The option searches for routines provided in a --IINNLLIINNEE::mmuusstt list option, in the _f_i_l_e_n_a_m_e specified. The _f_i_l_e_n_a_m_e provided by this option must be generated using the --IIPPAA --cc option. The file generated contains information used to perform cross-file inlining. For example, suppose the following two files exist: ffoooo..ff and bbaarr..ff. The following is part of the code from ffoooo..ff: program main .... call bar() end The following is partial code from bbaarr..ff: subroutine bar() ... end To inline bbaarr into mmaaiinn using the stand-alone inliner, compile bbaarr..ff in the following way: f77 -n32 -IPA -c bar.f This produces the file, bbaarr..oo. To inline bbaarr into ffoooo..ff, use: f77 -n32 foo.f -INLINE:must=bar_:file=bar.o kkeeeepp__ppuu__oorrddeerr[[==_s_e_t_t_i_n_g]] Preserves source subprogram ordering. The default is OOFFFF. lliibbrraarryy==_n_a_m_e Identifies archive libraries where the inliner should search for subprograms. This option is similar to --IINNLLIINNEE::ffiillee==, described previously, where the files (..oo) in the archived library (..aa) must have been generated using the --IIPPAA --cc options. For example, suppose function FFOOOO is defined in ffooooffiillee..ff. The ffooooffiillee..ff was compiled with --IIPPAA --cc and transformed into an archive with this command: aarr rrvv ffoooolliibb..aa ffooooffiillee..oo The following command will inline the function ffoooo from ffooooffiillee..oo (which is automatically extracted from ffoooolliibb..aa) into bbaarr..cc via the crossfile inlining mechanism described above: cc -n32 -INLINE:must=foo:library=foolib.a bar.c lliisstt[[==_s_e_t_t_i_n_g]] List inlining actions as they occur to ssttddeerrrr. The default is OOFFFF. mmaaxx__ppuu__ssiizzee__iinnlliinnee[[==_n]] Limits the size of inlined subprograms to _n. The default is 5000. Inlining is disabled if, after inlining, the caller exceeds this size. mmuusstt==_n_a_m_e_1[[,,_n_a_m_e_2]] Directs IPA to always attempt to inline any routines with names _n_a_m_e_1, _n_a_m_e_2, independent of the default inlining heuristic. For C++, the names given must be the "mangled" names (see NOTES). For Fortran, the name given may be either the original name, or the external name with the underscore appended by the compiler. In all cases, the option applies to all routines encountered with the given name, whether ssttaattiicc or eexxtteerrnn. In C, a pragma suppressing inlining at a particular callsite takes precedence over this option. nneevveerr==_n_a_m_e_1[[,,_n_a_m_e_2]] Directs IPA to never attempt to inline any routines with the names _n_a_m_e_1, _n_a_m_e_2, independent of the default inlining heuristic. For C++, the names given must be the "mangled" names (see NOTES). For Fortran, the name given may be either the original name, or the external name with the underscore appended by the compiler. In all cases, the option applies to all routines encountered with the given name, whether ssttaattiicc or eexxtteerrnn. A pragma requesting inlining at a particular callsite takes precedence over this option. nnoonnee Changes the default inlining heuristic so the compiler does not attempt to inline any routines which are not specified by a mmuusstt option or a pragma requesting inlining, either for the routine or for a specific callsite. This option conflicts with aallll; aallll takes precedence if both are specified. pprreeeemmpptt[[==_s_e_t_t_i_n_g]] Enables inlining of functions marked preemptible in the standalone inliner. The default is OOFFFF. Such inlining prevents another definition of such a function in another DSO from pre-empting the definition of the function being inlined. ssppeeccffiillee==_f_i_l_e_n_a_m_e Opens _f_i_l_e_n_a_m_e to read additional options. The specification file contains zero or more lines with inliner options in the form expected on the command line. For example, the file might contain a single line, similar to the following: INLINE:never=errfunc:must=accessor,solver It can also contain multiple lines, as in the following: INLINE:all INLINE:never=errfunc The ssppeeccffiillee option cannot occur in a specification file, so specification files cannot invoke other specification files. ssttaattiicc[[==_s_e_t_t_i_n_g]] Performs inlining of static functions in the standalone inliner. _s_e_t_t_i_n_g can be either OONN or OOFFFF. C/C++: The default is TTRRUUEE at --OO22 optimization levels, FFAALLSSEE otherwise. IIPPAA OOppttiioonnss The IIPPAA options control the interprocedural analyses and transformations performed. Using the group name without any options (for example, --IIPPAA) invokes IPA with the default settings. When --aappookkeeeepp, --ppccaakkeeeepp, or --ppffaakkeeeepp are specified in conjunction with --iippaa or --IIPPAA, the default settings for IPA suboptions are used with the exception of the iinnlliinnee==_s_e_t_t_i_n_g suboption, which is set to OOFFFF. The individual controls in this group are: aaddddrreessssiinngg[[==_s_e_t_t_i_n_g]] Enables or disables the analysis of address operator usage. _s_e_t_t_i_n_g can be either OONN or OOFFFF. --IIPPAA::aalliiaass==OONN is a prerequisite. The default is OOFFFF. aaggggrr__ccpprroopp[[==_s_e_t_t_i_n_g]] Enables or disables aggressive interprocedural constant propagation. _s_e_t_t_i_n_g can be either OONN or OOFFFF. Attempts to avoid passing constant parameters, replacing the corresponding formal parameters by the constant values. By default, less aggressive interprocedural constant propagation is done. The default is OOFFFF. aalliiaass[[==_s_e_t_t_i_n_g]] Enables or disables alias/mod/ref analysis. _s_e_t_t_i_n_g can be OONN or OOFFFF. The default is OOFFFF. aauuttooggnnuumm[[==_s_e_t_t_i_n_g]] Determines the optimal value of the --GGnnuumm option. _s_e_t_t_i_n_g can be OONN or OOFFFF. This option identifies a size bound below which data can be allocated relative to the global pointer and accessed cheaply. This optimization is turned off when --mmuullttiiggoott is specified in the linker command line. The default is OONN. See also --IIPPAA::GGnnuumm. ccggii[[==_s_e_t_t_i_n_g]] Enables or disables constant global variable identification. _s_e_t_t_i_n_g can be OONN or OOFFFF. This option marks non-scalar global variables which are never modified as constant, and propagates their constant values to all files. The default is OONN. ccoommmmoonn__ppaadd__ssiizzee==_n Specifies the amount by which to pad common block array dimensions. By default, the compiler automatically chooses the amount of padding to improve cache behavior for common block array accesses. ccpprroopp[[==_s_e_t_t_i_n_g]] Enables or disables interprocedural constant propagation. _s_e_t_t_i_n_g can be OONN or OOFFFF. This option identifies formal parameters which always have a specific constant value. The default is OONN. See also --IIPPAA::aaggggrr__ccpprroopp. ddeepptthh==_n This option is identical to mmaaxxddeepptthh==_n. ddffee[[==_s_e_t_t_i_n_g]] Enables or disables dead function elimination. _s_e_t_t_i_n_g can be OONN or OOFFFF. This option removes subprograms which are never called from the program. The default is OONN. ddvvee[[==_s_e_t_t_i_n_g]] Enables or disables dead variable elimination. _s_e_t_t_i_n_g can be OONN or OOFFFF. This option removes variables which are never referenced from the program. The default is OONN. eecchhoo[[==_s_e_t_t_i_n_g]] Echo (to ssttddeerrrr) the compile commands and the final link command which are invoked from IPA. _s_e_t_t_i_n_g can be OONN or OOFFFF. This can help monitor progress of a large system build. The default is OOFFFF. ffoorrcceeddeepptthh==_n Sets inline depths. Instead of the default inlining heuristics, this options directs IPA to attempt to inline all functions at a depth of (at most) _n in the callgraph, where functions which make no calls are at depth 0, those which call only depth 0 functions are at depth 1, and so on. This ignores the default heuristic limits on inlining. GGffaaccttoorr==_n Sets percentage for GOT multiplication. _n is the percentage used to multiply the estimated external GOT entries for estimating the total ..ggoott size. A value of _n=200 means that IPA will multiply the estimated external GOT entries by 2 to get the estimated total ..ggoott size. The default is 220000. GGnnuumm==_n User-specified GGnnuumm. The default is no limit. GGssppaaccee==_n User-specified size (in bytes) for the area where IPA can allocate data that can be referenced relative to the global pointer. The default is 64 Kbytes, which is the maximum valid value. ggpp__ppaarrttiittiioonn[[==_s_e_t_t_i_n_g]] Enables partitioning for archiving different GP-groups, as specified by the user externally or determined by IPA internally. _s_e_t_t_i_n_g can be OONN or OOFFFF. This option basically enables --IIPPAA ppiiccoopptt in the presence of --mmuullttiiggoott. The default is OOFFFF. iinnlliinnee[[==_s_e_t_t_i_n_g]] Performs inter-file subprogram inlining during main IPA processing. _s_e_t_t_i_n_g can be OONN or OOFFFF. The default is OONN. This does not affect the standalone inliner. iinnttrriinnssiiccss==_n Sets the number of Fortran intrinsic functions in the GOT area. This number is added to the estimated external GOT entries to get the estimated total ..ggoott size. IPA has difficulty in estimating the number of Fortran intrinsic functions that will be added by the Lowerer after the IPA phase. kkeeeepplliigghhtt[[==_s_e_t_t_i_n_g]] Directs IPA to not send --kkeeeepp to the compiler, in order to save space. _s_e_t_t_i_n_g can be OONN or OOFFFF. The default is OOFFFF. lliinneeaarr[[==_s_e_t_t_i_n_g]] Sets linearization of array references. _s_e_t_t_i_n_g can be OONN or OOFFFF. When inlining Fortran subroutines, IPA tries to map formal array parameters to the shape of the actual parameter. It may not always be able to always map it. In the case that it cannot map the parameter, it linearizes the array reference. By default, it will not inline such callsites because they may cause performance problems. The default is OOFFFF. mmaapp__lliimmiitt==_n Controls when IPA enables sspp__ppaarrttiittiioonn. _n is the maximum size (in bytes) of input files mapped before IPA does --IIPPAA sspp__ppaarrttiittiioonn. mmaaxxddeepptthh==_n Directs IPA to not attempt to inline functions at a depth of more than _n in the callgraph, where functions which make no calls are at depth 0, those which call only depth 0 functions are at depth 1, and so on. Inlining remains subject to overriding limits on code expansion. See also ffoorrcceeddeepptthh, ssppaaccee, and pplliimmiitt. mmaaxx__jjoobb==_n Limits the maximum parallelism when invoking the compiler after IPA to (at most) _n compilations running at once. The default is 2 on a uniprocessor host, 4 on a multiprocessor host. mmuullttii__cclloonnee==_n Specifies the maximum number of clones that can be created from a single procedure. By default, this value is 0. Aggressive procedure cloning may provide opportunities for interprocedural optimization, but it also may significantly increase the code size. nnooddee__bbllooaatt==_n When used in conjunction with IIPPAA::mmuullttii__cclloonnee, this specifies the maximum percentage growth of the total number of procedures relative to the original program. ppaarrttiittiioonn__ggrroouupp==[[ssyymmbboollnnaammee[[%%_s_y_m_b_o_l]]||_f_i_l_e_n_a_m_e%%FF]]]]...... Specifies EXTERNAL symbols belonging to the same group. All unspecified symbols are considered by IPA as belonging to the COMMON group, which has the properties of always being in memory and available for inlining. Following the ssyymmbboollnnaammee, the user can specify the properties for that symbol by adding a percentage symbol (%), followed by the property wanted. _s_y_m_b_o_l can be II or GG. II indicates symbol is used only within the partition, or GG indicates symbol should be marked as GP-relative, for DDAATTAA symbols only. Instead of specifying the symbol, the user can specify a ggpp__ppaarrttiittiioonn per file, as in the following: partition_group=file_name%F Then every defined EXTERNAL symbol that exists in that file will have the same group. ffiillee__nnaammee must be specified in the same way that the file is specified in the link-line. See the following example: cc -IPA:gp_partition=on:partition_group= /usr/tmp/p007.o%F:partition_group=./add.o%F /usr/tmp/p007.o ./add.o ppiiccoopptt[[==_s_e_t_t_i_n_g]] Performs PIC optimizations. This involves turning preemptible symbols to non-preemptible symbols whenever possible, either through IPA's own analysis or through user specifications (required to build DSOs). The following are major benefits of this action: * Enables other IPA optimizations such as inlining, constant propagation, DFE, etc. * Turns indirect calls to direct calls. * Eliminates the generation of GP-prologs, thus generating fewer instructions. The preceding benefits are automatically accomplished by IPA for building executables. To obtain similar benefits for building DSOs, the user must specify which symbols are preemptible. This can be done by using the lldd --eexxppoorrttss__ffiillee option. See the lldd man page for details. The default is OONN. pplliimmiitt==_n Stops inlining into a particular subprogram once it reaches size _n in the intermediate representation. The default is 2500. rreelloopptt[[==_s_e_t_t_i_n_g]] Enables optimizations similar to those achieved with the compiler options --OO33 and --cc, where objects are built with the assumption that the compiled objects will be linked into a call-shared executable later. _s_e_t_t_i_n_g can be OONN or OOFFFF. In effect, optimizations based on position-dependent code (non-PIC) are performed on those objects. The default is OOFFFF. ssppaaccee==_n Stops inlining when the program size has increased by _n%. For example, _n=20 limits code expansion due to inlining to approximately 20%. The default is 100%. sspp__ppaarrttiittiioonn==[[_s_e_t_t_i_n_g]] Enables partitioning for disk/address-saving purpose. _s_e_t_t_i_n_g can be OONN or OOFFFF. Mainly used for building huge programs (for example, PTC). Partitioning should normally be done by IPA internally. The default is OOFFFF. ssppeeccffiillee==_f_i_l_e_n_a_m_e Opens _f_i_l_e_n_a_m_e to read more options. A specfile contains zero or more of the options allowed by IPA. In the following example, --IIPPAA::ssppeeccffiillee==ooppttiioonn__ffiillee, the ooppttiioonn__ffiillee can be used to specify anything for -IPA as if it is specified in the command line, as in this example: -IPA:gp_partition=on:partition_group=p007.o%F:partition_group=add.o%F Because ssppeeccffiillee== is not legal within a specfile, a specfile cannot point at other specfiles. uussee__iinnttrriinnssiicc[[==_s_e_t_t_i_n_g]] Enables loading the intrinsic version of standard library functions. This option causes inlining of the mmaalllloocc library. This improves small object allocations, but is not mmpp safe. _s_e_t_t_i_n_g can be OONN or OOFFFF. The default is OOFFFF. NNOOTTEESS Both IPA and standalone inlining are disabled when --gg is specified on the compiler's command line. CC//CC++++ MMaanngglleedd NNaammee For specifying routine names to the --IINNLLIINNEE::nneevveerr==_n_a_m_e and --IINNLLIINNEE::mmuusstt==_n_a_m_e options for C++ programs, the _m_a_n_g_l_e_d internal name must be used. Because C++ allows overloading (that is, the use of the same name for multiple objects which can be distinguished by type), it uses internal names which are constructed from the original name and an encoded version of the object's type. To find this mangled name, do the following: * Compile the source module where the name is defined, as in this example: CC -c source.cxx -o source.o * Use the original name to find the mangled name in the object file using nnmm(1) and ggrreepp(1). For example, if the original name was _m_y_s_u_b, use the following: nm -B source.o | grep mysub 0f89f950 T mysub__10yourclassFv 0f89facc T mysub__10myclassFv * The previous commands might produce several potential matches, particularly if overloading is actually occurring. If so, use the cc++++ffiilltt filter to determine which one is the one you want: /usr/lib/c++/c++filt mysub__10myclassFv myclass::mysub(void) You can continue entering possible names until one of them matches the name you want. SSEEEE AALLSSOO cccc(1), ff7777(1), lldd(1) ddssoo(5) _M_I_P_S_p_r_o _C _a_n_d _C++ _P_r_a_g_m_a_s, publication 007-3587-001 _C _L_a_n_g_u_a_g_e _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l, publication 007-0701-120 _C_o_m_p_i_l_e_r _I_n_f_o_r_m_a_t_i_o_n _F_i_l_e (_C_I_F) _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l _M_I_P_S_p_r_o _F_o_r_t_r_a_n _7_7 _P_r_o_g_r_a_m_m_e_r'_s _G_u_i_d_e _M_I_P_S_p_r_o _7 _F_o_r_t_r_a_n _9_0 _C_o_m_m_a_n_d_s _a_n_d _D_i_r_e_c_t_i_v_e_s _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l _M_I_P_S_p_r_o _6_4-_B_i_t _P_o_r_t_i_n_g _a_n_d _T_r_a_n_s_i_t_i_o_n _G_u_i_d_e This man page is available only online.